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Kerberos Options for DHCPv6 
Abstract 
This document defines four new options for the Dynamic Host 
Configuration Protocol for IPv6é (DHCPv6). These options are used to 
carry configuration information for Kerberos. 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6784. 
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Le 


Introduction 


Kerberos Version 5 [RFC4120] is a trusted third-party authentication 
system. Each organization wishing to use Kerberos establishes its 
own "realm", and each client is registered as part of that realm. At 
least one Key Distribution Center (KDC) is required for the operation 
of a Kerberos realm. 


When a client wishes to communicate with, and be authenticated to, a 
Kerberos application server (also a client of the KDC), the client 
identifies itself, and its realm, to the KDC and acquires a 
credential from the KDC. The client then presents the credential to 
the Kerberos application server, which can use the credential to 
authenticate the client. The client needs to know at least one IP 
address for a KDC in order to initiate this process. 


One example of the application of this protocol is as follows. A 
student might want to use a shared, public workstation, one that is 
not configured for Kerberos. If there is a mechanism for the 
workstation to obtain a realm name and IP address for a KDC, then a 
student need only input a user-id and pass phrase to be able to use 
Kerberos. 


The Kerberos V5 specification [RFC4120] defines the use of DNS SRV 
records [RFC2782] for KDC discovery. Some systems, such as 
industrial systems, do not use DNS. Such systems already have their 
own name spaces and their own name resolution systems, including 
preconfigured mapping tables for devices, and do not use Fully 
Qualified Domain Names. However, many of these systems do use DHCP. 


Adding a DNS server to such systems may decrease the reliability of 
the system and increase the management cost. In such an environment, 
another mechanism is needed to provide an IP address for the KDC. 

For the PacketCable Architecture [PCARCH], RFC 3634 [RFC3634] defines 
the KDC Server Address sub-option for the DHCPv4 CableLabs Client 
Configuration option. However, a mechanism is still needed to 
provide a realm name and an IPv6 address -- one that does not depend 
on any external architecture. 


This document defines a Kerberos option for DHCPv6 that provides a 
realm name and/or a list of KDC IP addresses. This option does not 
replace or modify any of the existing methods for obtaining this 
information. 
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2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
It is assumed that the readers are familiar with the terms and 
concepts described in DHCPv6 [RFC3315], Kerberos V5 [RFC4120], and 
DNS SRV [RFC2782]. 


3. Kerberos Options 


This document defines four DHCPv6 configuration parameters for 
Kerberos. 


Kerberos Principal Name Option 
Kerberos Realm Name Option 
Kerberos Default Realm Name Option 
Kerberos KDC Option 


This section describes the format of each option and the usage of 
each field in that option. 


These options, except for the Kerberos KDC Option, MUST NOT appear 
more than once in a DHCPv6 message. 


3.1. Kerberos Principal Name Option 
The Kerberos Principal Name Option carries the name of a Kerberos 
principal. This is sent by the client to the DHCPv6 server, which 


MAY use it to select a specific set of configuration parameters, 
either for a client or for a Kerberos application server. 
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The format of the Kerberos Principal Name Option is: 


0 I 2 3 
0-1-2 34 9°6 7°38 9. 0-123°4-56 7°8 9. 02 2.349.678 9 0 2 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OPTION_KRB_PRINCIPAL_NAME ű | option-len 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


principal-name 
(variable length) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Oo option-code (16 bits): OPTION_KRB_PRINCIPAL_NAME (75) 

o option-len (16 bits): length of the principal-name field. 

Oo principal-name (variable): a client principal name. The encoding 
of the principal-name field MUST conform to the definition of 
"PrincipalName" in Section 5.2.2 of RFC 4120 [RFC4120]. 

3.2. Kerberos Realm Name Option 
The Kerberos Realm Name Option carries a Kerberos realm name. A 
DHCPv6 client uses this option to specify to a DHCPv6 server which 


realm the client wants to access. 


The format of the Kerberos Realm Name Option is: 


0 1 2 3 

0.1 23-4. 3 6 OF 8 90-0 1 2. 3:45 6. FB. G0. 1284 6 OF BO 0. 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OPTION_KRB_REALM_NAME | option-len 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


realm-name 
(variable length) 


+-+-4-4+-+-+4+-4+-+-+-4-4+-+4-4-4+-4+-4+-4-4+-4-4-4+-4+-+4+-4-4+-4+-4-4+-4-4+-4+-4-4+ 
o option-code (16 bits): OPTION_KRB_ REALM NAME (76) 


o option-len (16 bits): the length of the realm-name field in 
octets. 


o realm-name (variable): a realm-name. The encoding of the 


realm-name field MUST conform to the definition of "Realm" in 
Section 5.2.2 of RFC 4120 [RFC4120]. 
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3.3. Kerberos Default Realm Name Option 


The Kerberos Default Realm Name Option is used to specify a default 
realm name for the Kerberos system. A DHCPv6 server uses this option 
to specify the default realm name to both clients and Kerberos 
application servers. 


The option-code of this option is OPTION_KRB_DEFAULT_REALM NAME (77). 
The format and usage of the option-len and realm-name fields are 
identical to those for the Kerberos Realm Name Option. 


3.4. Kerberos KDC Option 


The Kerberos KDC Option is used to provide configuration information 
about a KDC. 


The format of the Kerberos KDC Option is: 


N 
w 


0r de 23 
+-+-+-+ 


+D 
ol 
+0 
oO 


+-+-+-+-+-+- 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Transport Type | Port Number | 
$ota—t—t— 4-44-44 t ttt ttt oti titi titi tat 


| KDC IPv6 address ofeach as PS Sa + 
| | 


+-4-4+-4-4-4-4-4+-4-4-4+-4+-4+-4+-4+-4+-4+-4+-4+-4-4-4-4-4-4 


realm-name 
(variable length) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Oo option-code (16 bits): OPTION_KRB_KDC (78) 


o option-len (16 bits): 23 + the length of the realm-name field in 
octets. 


o Priority (16 bits): see the description of the Weight field. 
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o Weight (16 bits): the Priority and Weight fields provide a hint to 
the client as to which KDC to select. The usage of the Priority 
and Weight values MUST follow the specification for DNS SRV 
[RFC2782]. 


o Transport Type (8 bits): The Transport Type specifies the 
transport protocol used for Kerberos. Kerberos [RFC4120] defines 
UDP and TCP transports. Exchanges over TCP are further described 
in [RFC5021], while the transport of Kerberos over Transport Layer 
Security (TLS) is described in [RFC6251]. 


The transport type is defined below. 


Value Transport Type 
0 Reserved 

1 UDP 

2 TCP 

3 TLS 

4-254 Unassigned 

255 Reserved 


o Port Number (16 bits): the port number on which the KDC listens. 
o KDC IPv6 address (128 bits): the IPv6 address of the KDC. 


o realm-name (variable): the name of the realm for which the 
specified KDC provides service. The encoding of the realm-name 
field MUST conform to the definition of "Realm" in Section 5.2.2 
of RFC 4120 [RFC4120]. 


4. Client and Server Operation 


This section describes the operations of the client and server. It 
assumes that the client has been configured with a principal name. 


If a client requires a realm name, the client sends a DHCPv6 Option 
Request Option (ORO) specifying the Kerberos Default Realm Name 
Option. The DHCPv6 server responds with a Reply message containing a 
Kerberos Default Realm Name Option. 


If a client requires configuration parameters for a KDC, the client 
sends a DHCPv6 ORO specifying the Kerberos KDC Option. The client 
MAY include a Kerberos Principal Name Option. The client MAY include 
a Kerberos Realm Name Option. 


The DHCPv6 server replies with one or more sets of configuration 
parameters for a Kerberos KDC. If the client has specified either a 
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Kerberos Principal Name Option or a Kerberos Realm Name Option, then 
the DHCPv6 server MAY use those parameters to select specific sets of 
configuration parameters. 


Where the server replies with more than one set of configuration 
parameters, the usage of the Priority and Weight fields by the client 
MUST follow the specification for DNS SRV [RFC2782]. 


The client MAY include other options with data values as hints to the 
DHCPv6 server about parameter values the client would like to have 
returned; this is specified in Section 18.1.5 of RFC 3315 [RFC3315]. 


4.1. KDC Discovery for a Client 


When a client implements both the DNS method defined by 

Section 7.2.3.2 of [RFC4120] and the DHCP method defined by this 
document, the choice of method is determined by local policy. The 
administrator of the realm usually defines the method as part of the 
configuration of the client before the client is installed. 


When no criteria have been specified and the client could get the 
Kerberos information from either the DNS server or the DHCPv6 server, 
then the information from DNS SHOULD be preferred. 

5. IANA Considerations 


IANA has assigned four option codes from the DHCPv6 Option Codes 
registry for the following: 


75 OPTION_KRB_PRINCIPAL_NAME 


76 OPTION_KRB_REALM_ NAME 


77 OPTION_KRB_DEFAULT_REALM NAME 


78 OPTION_KRB_KDC 


IANA has created the Kerberos Message Transport Types sub-registry, 
under the Kerberos Parameters registry. The initial entries are 
described in Section 3.4. 


The assignment of future entries is by "IETF Review" policy as 
described in BCP 26 [RFC5226]. Per that policy, a document specifies 
the symbolic name of such entries, which are assigned numeric codes 
by IANA once publication is approved. 
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6. 


Security Considerations 
The security considerations in RFC 3315 [RFC3315] apply. 


DHCPv6 messages can be modified in transit. If an adversary modifies 
the response from a DHCPv6 server or injects its own response, a 
client may be led into contacting a malicious KDC. Both cases are 
categorized as a Denial-of-Service (DoS) attack. However, a 
malicious KDC does not know the shared key and so is unable to 
proceed any further with the exchange. If a client receives a 
response from such a KDC, the client can use the shared key to detect 
that the message originates from a malicious KDC. 


A shared, unconfigured workstation may obtain its KDC information, 
and default realm, via DHCPv6. Such a workstation may not have a 
host or other service key, and thus it may be unable to validate the 
Ticket-Granting Ticket issued by the KDC. A modified DHCPv6é response 
would then result in the workstation talking to a malicious KDC, and 
the workstation would not be able to detect that this has happened. 
This in turn could allow access by unauthorized users. 


To minimize potential vulnerabilities, a client SHOULD use DHCPv6 
authentication as defined in Section 21 of RFC 3315 [RFC3315]. 


Kerberos information may be manually configured on the client before 
requesting information from DHCPv6. Manual configuration of the 
device SHOULD be preferred to configuration via the DHCPv6é server. 
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Appendix A. An Example of the Operation of the Client 


When no criteria have been specified and the client could get the 
Kerberos information from either the DNS server or the DHCPv6 server, 
then the information from DNS SHOULD be preferred. The following is 
an informational guide for the client in such an environment. 


No Resp. or 


hesssSssssss2 + DNS “Ents, tS SS=SSSSs= + No Resp. 
Start --> | Ask DHCP(1)| --------- > | Ask DNS(3)| ------ > 
aca la a ie + fess Ssnssose + Terminate (4) 
/ \ \ 
Only KRB / \ DNS and \ KRB Info. 
Info. / \ KRB Info. \ 
/ ai \ 
V 
V No Ans. +----------- + KRB Info. V 
Use- Infos <35 amni | Ask DNS (6) | --------- > Use Info. 
from DHCP prre + from DNS 
(2), (7) (5), (8) 
Abbreviations: 
Resp.: Response 
Info.: Information 
KRB : Kerberos 


1) Initially, the client requests both DNS and Kerberos information 
from the DHCPv6 server. 


2) If the DHCPv6 server replies with Kerberos information and not 
with DNS information, then the client uses that information. 


3) If the DHCPv6 server does not reply or replies with only DNS 
information, then the client requests Kerberos information from 
the DNS server. 


4) If the client gets no response or no Kerberos information from 
the DNS server, then the client terminates the process. 


5) If the client gets Kerberos information from the DNS server, then 
the client uses that information. 


6) If, as the result of (1), the DHCPv6 server replies with both DNS 


and Kerberos information, then the client requests Kerberos 
information from the DNS server. 
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7) If the client gets no response from the DNS server, then the 
client uses the Kerberos information from the DHCPv6 server. 


8) If, as the result of (6), the DNS server replies with Kerberos 
information, then the client uses the information from the DNS 
server and not that from the DHCPv6 server. 
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